home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1991 / Mar 91 / MacApp.Tech$ 3⁄1⁄91 / 3127-Performance Testing-Feb91 < prev    next >
Encoding:
Text File  |  1991-04-01  |  2.9 KB  |  67 lines  |  [TEXT/GEOL]
  1. Item    5931212                         28-Feb-91        05:39PST
  2.  
  3. From:   POWERUP.ENG                     Power Up Software,PRT
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.  
  7. ------------------------------------------------------------------------------
  8.  
  9. Sub:    Performance Testing
  10.  
  11. Attn:   MacApp.Tech$
  12. SentBy: James Plamondon
  13. Subject:   Performance Testing
  14. Gentlepersons,
  15.  
  16. I think it was Knuth who said that "even the most elegant design must someday
  17. face reality" (or words to that effect).  Reality is hitting my program (which
  18. has no claim to elegance) right between the eyes — its performance is
  19. exceedingly disappointing.
  20.  
  21. To address this problem, I have turned to the standard MPW performance
  22. techniques:  the routines described in {PInterfaces}Perf.p and the
  23. PerformReport tool.
  24.  
  25. The result has been rather disappointing.  As always with Mac programs, my
  26. application is spending most of its time in obscure ROM routines that my
  27. application is not calling directly.  For example, here's where my application
  28. is spending about 50% of its time when reading in a file:
  29.  
  30. Num     Segment  :       Procedure     Def   Prob   Poss    Prob%
  31. 127      ROMIIfx :     DOSCSIMSGOUT   1374      0      0    20.5%
  32. 127      ROMIIfx :          EMT1010    658      0      0     9.8%
  33. 127      ROMIIfx :         HEAPGUTS    409      0      0     6.1%
  34. 127      ROMIIfx :      MMHPROLOGUE    280      0      0     4.1%
  35. 127      ROMIIfx :    A32BKCOMPACTS    270      0      0     4.0%
  36. 127      ROMIIfx :            DELAY    133      0      0     1.9%
  37. 127      ROMIIfx :         FASTREAD    105      0      0     1.5%
  38. 127      ROMIIfx :  MMNOERREPILOGUE    102      0      0     1.5%
  39. 127      ROMIIfx :        FINDDITEM     81      0      0     1.2%
  40.  
  41. Now, from the fact that 20% of the time is being spent in DOSCSIMSGOUT, which
  42. must have something to do with reading in the file from the hard drive, I know
  43. that it's time to write that file-buffering code I've been putting off, so
  44. that I don't hit the disk so often.
  45.  
  46. But what's all the rest of this stuff?  EMT1010 — is that a Emergency Medical
  47. Technician Manager call?  Is it being called because the HEAPGUTS are spilling
  48. out?  Is it trying to A32BKCOMPACTS them back into the heap, after a DELAY to
  49. FINDDITEM that cut him open?  I'm afraid my paltry intellect can't derive much
  50. information from a FASTREAD of this data.
  51.  
  52. This seems like "dark ages" programming.  I would think that it would be
  53. possible for a tool to generate a call tree, in which the amount of time spent
  54. in each node was the sum of the time spent in itself and each of its children.
  55.  Is this NP-Complete or something?  Would it require a Cray to analyse "hello,
  56. world?"  Does such a tool exist on the Mac (or anywhere else)?
  57.  
  58. If not, does anyone have any suggestions as to how I should go about analysing
  59. the cryptic results of PerformReport?
  60.  
  61. Lazy as always, I remain
  62.  
  63. Yours,
  64.  
  65. James Plamondon
  66.  
  67.